Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9710/000015_owner-urn-ietf _Mon Oct 27 22:14:00 1997.msg

Internet Message Format | 1997-10-28 | 6KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id WAA12624
    for urn-ietf-out; Mon, 27 Oct 1997 22:14:00 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with ESMTP id WAA12619
    for <[e-mail]>; Mon, 27 Oct 1997 22:13:56 -0500 (EST)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50])
    by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id WAA05651;
    Mon, 27 Oct 1997 22:13:52 -0500 (EST)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa00940;
          27 Oct 97 18:10 PST
To: [e-mail]
cc: Dan Connolly <[e-mail]>, [e-mail], [e-mail],
        [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail], [e-mail],
        [e-mail]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs
In-reply-to: Your message of "Mon, 27 Oct 1997 14:33:39 EST."
             <[e-mail]>
Date: Mon, 27 Oct 1997 18:04:43 -0800
From: "Roy T. Fielding" <[e-mail]>
Message-ID:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: "Roy T. Fielding" <[e-mail]>
Errors-To: [e-mail]

One of the nice things about being out with a cold for three days
is you get to see the tail end of these conversations before being
able to reply.

When I agreed to revise and combine the URL specifications over a year ago,
the first question I asked of the other authors is whether I should write
it as the URI syntax or the URL syntax.  The question of whether or not
the two are equivalent was never an issue --- the reason I asked the question
was to determine if it was politically feasible to make the specification
match the URI/URL/URN design, or if it would be better to maintain the
artificial distinction for the purpose of getting the spec out faster.
A year later, it is clear we made the wrong choice.

Leslie Daigle writes:
>By the way -- note that this is the
>
>    "Uniform Resource Locators (URL): Generic Syntax and Semantics"
>
>draft, and it's the "and semantics" parts that concerns me particularly
>when talking about sweeping URN syntax into this and calling it the URI
>syntax document.

The definition of URN given in RFC2141 and its relatives is a subset of
the definition of a URL scheme, both in terms of semantics and syntax.
The URN requirements apply additional constraints on the naming authority
and the syntax, but those constraints are no different than what can be
applied to any new URL scheme.  URNs are already bound by the syntax of
a URL in order to fulfill one of the earliest requirements --- that URNs
be usable in the same context as one would use a URL reference.

Please note that the "L" in "URL" represents "Locator", not "Location".
Any naming scheme that requires there exist some mechanism for resolution,
whether or not the mechanism is currently in operation, changes over time,
or subject to multiple levels of indirection, is a locator.
There do exist names that are not locators, but those names are not URNs.

The argument that fragment identifiers might not be useful with URNs
is ridiculous.  A fragment is a client-side specialization of the
identification of a resource, and thus is independent of both URLs and URNs
except for the fact that they occur within the same data field.
They are a property of some URL references, and thus a required property
of some URN references.  RFC2141 does recognize that requirement, even
if it does so in a particularly wishy-washy fashion that should have been
unacceptable in any Proposed Standard.

Whether or not a URN is allowed to be used in relative form is not
relevant.  There are many URL schemes which have no use for relative
forms.  There are many demonstrated uses for abbreviated names, so it
is a pity that the "urn" syntax was chosen to exclude their possibility
using the standard relative URL algorithm.  Instead, you will be stuck
with application-dependent macros.  They will be created whether you like
them or not --- the desire to abbreviate is part of the human psyche
and not subject to IETF standardization.

>#2 is a definite "no"; URN namespaces are _not_ just like URL schemes.  THey
>have implications of ownership, maintaingin registries and validation
>services, and a whole set of requirements centred on uniqueness, etc.

Those are all scheme-dependent requirements.  The only thing the "urn"
scheme does is gather a bunch of naming authorities under a single,
as-yet-undefined set of requirements.  There is no RFC that defines
those requirements, which is why I didn't reference anything beyond
the original Informational spec.  If the "urn" scheme is to be useful,
it will need to require things which some existing name services do not
support, and thus there will exist location-independent URLs which
are not URNs.  Heck, that is already the case today.

I do agree that URN NIDs are not URL schemes, and should not be in
the same registry.  They don't even have the same syntax.

If this sounds a bit confusing, please recall that I argued many times
against the URN WG using the name "urn" for what was clearly only one
possible scheme for defining names.  Monopolizing the namespace is
counterproductive.

I can easily change the URL spec such that it covers all locators and
still gives autonomy over the "urn" scheme's namespace to the set of
URN RFCs.  If Keith gives the okay (I believe Harald has already suggested
it more than once), then I'll do that later this week.

 ...Roy T. Fielding
    Department of Information & Computer Science    ([e-mail])
    University of California, Irvine, CA 92697-3425    fax:[phone]
    http://www.ics.uci.edu/~fielding/